Systems and methods for managing content provided through a mobile carrier

ABSTRACT

A wireless network carrier can track and monitor third-party network-enabled applications (pods) that are accessed by, and billed to, users of the wireless network carrier through a mobile content platform, and to control access to such third-party network-enabled applications (pods) based on selectable criteria for the performance and user-based feedback related to each content application (pod). The network-enabled applications can also be registered with the mobile content platform through an intermediary, such as an aggregator. The network-enabled application can then be associated with the intermediary so that the intermediary receives a share of the revenue generated by the network-enabled application.

RELATED APPLICATIONS INFORMATION

This application claims priority under 35 U.S.C. 119(e) to U.S.Provisional Patent Application Ser. No. 60/789,388, filed Apr. 4, 2006,entitled “Content Application Manager,” which is incorporated herein byreference as if set forth in full.

This Application is also related to U.S. patent application Ser. No.,11/516, 921, filed Sep. 6, 2006, entitled “Automated Billing andDistribution Platform for Application Providers,” which is alsoincorporated herein by reference as if set forth in full.

BACKGROUND INFORMATION

1. Field

The present invention relates to a method and system providing thecapability for a wireless network carrier to track and monitor contentapplications (pods) that are accessed by, and billed to, users of thewireless network carrier, and to control access to such contentapplications (pods) based on selectable criteria for the performance anduser-based feedback related to each content application (pod).

2. Background

The invention described in commonly-owned U.S. patent application Ser.No. 11/516,921, entitled “Automated Mobile Phone Billing andDistribution Platform for Application Providers,” (the “'921application”), is directed to a method and platform through whichcontent application providers can easily and automatically connect to acommon platform in order to offer access and use of theirnetwork-enabled applications (pods) to a global community of mobilephone users through a variety of different mediums, while automaticallycharging the user for use of the application through the user's billingaccount with the wireless network carrier to which the user subscribes.In this manner, the community platform described in the '921 applicationallows an application provider to commercially offer an application to acommunity of mobile phone users without the need for the applicationprovider to have a contractual agreement with any of the wirelessnetwork carriers to which the mobile phone users respectively subscribe.Furthermore, the platform described in the '921 application providesapplication (pod) providers a simple and automatic way to register andpresent their applications for access, purchase and use by the globalcommunity by registering the applications in an automatic fashion thateliminates the need for a lengthy registration processing involvingmultiple layers of people and procedures.

According to the platform and methods described in the '921 application,an application provider can write an application pod and then registerthe pod with the community platform for automatic access to a communityof mobile phone users via various wireless network carriers. Forexample, an application provider may design and develop an applicationpod that allows a user to view current stock prices for selected stocksin which the user is interested. The application provider would thenregister the completed “stock price” application pod with the communityplatform, after which the pod would be available for access, purchaseand use by all mobile phone users that are members of the community. Amobile phone user could then subscribe to use the “stock price”application pod through the community platform, after which the usercould access and use the pod to check stock prices from within a typicalweb browser on a computer or on the user's mobile phone. As mentionedabove with respect to the '921 application, the community platformautomatically charges the user for use of (subscription to) theapplication pod through the user's existing billing account with thewireless network carrier to which the user subscribes.

Sometimes, difficulties arise with the access and use of third-partyapplication pods by users of a wireless network carrier, whether throughthe internet or through the user's mobile phone, because the third-partyapplication pods offered for billing through the wireless networkcarrier may have various, inconsistent types of pricing models. Thisresults in lack of clarity to a user of such pods, thereby leading tounexpected and/or unwanted billed charges on the user's account with thewireless network carrier. Also, some third-party application pods maynot deliver the service or product that was expected when the useragreed to pay for (opt in to) the application pod. These problems cancost the wireless network carrier a substantial amount of time and moneyto deal with. For example, the wireless network carrier may need tohandle a large volume of user complaints regarding the billing methodsand the quality of certain third-party application pods that are billedto users through the wireless network carrier. Furthermore, thesecomplaints may lead to the wireless network carrier having to creditsubstantial amounts to users' bills in order to offset billing bythird-party application pods that have applied unclear and inconsistentpricing models and which have delivered low quality product/services tousers, or none at all.

In addition, the delivery of low quality product/service and theunexpected billing to the user's accounts by various third-partyapplication pods may provide a bad image to the wireless network carrierthrough which such application pods are offered, and may lead users tocancel their service account with that wireless network carrier andsubscribe to another wireless network carrier. In order for a wirelessnetwork carrier to proactively monitor the billing practices and thequality of content provided by the numerous and various third-partyapplication pods offered through the wireless network carrier, thewireless network carrier would have to constantly review the pricingmodel offered by each application pod and also constantly review thecontent provided by each application pod to determine whether theapplication pod is providing content (product or service) of anacceptable quality to users of the wireless network carrier.

Proactive monitoring of all third-party application pods offered throughthe wireless network carrier can cost significant expenditures ofmanpower and money by the wireless network carrier. Also, when “problem”third-party application pods are identified, the wireless networkcarrier would need to deal individually with each third-party thatoperates the application pod to convince them to remedy the problem, orthen cancel the access and use of the third-party application podthrough the wireless network carrier, which also requires significanttime and expense on the part of the wireless network carrier.

Accordingly, a wireless network carrier needs a way to easily andefficiently monitor third-party content applications (pods) that areaccessed by, and billed to, users of the wireless network carrier, andto control access to such third-party content applications (pods) basedon selectable criteria for the performance and quality of each contentapplication (pod).

SUMMARY

The present invention generally provides a way for a wireless networkcarrier to track and monitor third-party network-enabled applications(pods) that are accessed by, and billed to, users of the wirelessnetwork carrier, and to control access to such third-partynetwork-enabled applications (pods) based on selectable criteria for theperformance and user-based feedback related to each content application(pod).

In one embodiment of the invention, a system and method are providedthat allow each of many mobile service providers to access a communityplatform through which the wireless network carrier can view allthird-party application pods that are offered through that wirelessnetwork carrier, monitor the use of each application pod and the pricingmodel of each application pod, and the revenue generated by eachapplication pod. In addition, the present invention allows the wirelessnetwork carrier to control the type of pricing model used by eachthird-party application pod and the consistent display of such pricingmodel to the users, along with the enforcement of the pricing model whenthe application pod bills users through the wireless network carrier.The present invention also allows the wireless network carrier todisconnect a third-party application pod from being accessed by users ofthe wireless network carrier based on monitored user feedback andcomments related to the third-party application pod in comparison toquality sensitivity criteria set by the wireless network carrier.

In other embodiments, the present application also provides thecapability for the wireless network carrier to automatically control theamount of marketing exposure (advertising) of each application pod tousers of the wireless network carrier. For example, the wireless networkcarrier can increase the amount of advertising of a particularapplication pod to a user on a user's displayed web page, if thatapplication pod is growing in popularity and meets acceptable billingand quality criteria set by the wireless network carrier.

In this manner, the wireless network carrier can efficiently andinexpensively for a wireless network carrier track and monitorthird-party content applications (pods) that are accessed by, and billedto, users of the wireless network carrier, and to control access to, andbilling practices of, such third-party content applications (pods) basedon selectable criteria for the performance and user-based feedbackrelated to each content application (pod).

These and other features, aspects, and embodiments of the invention aredescribed below in the section entitled “Detailed Description.”

BRIEF DESCRIPTION OF THE DRAWINGS

Features, aspects, and embodiments of the inventions are described inconjunction with the attached drawings, in which:

FIG. 1 is a diagram illustrating an example mobile community platformthat includes a content monitor configured in accordance with oneembodiment;

FIG. 2 is a diagram illustrating the functions that can be madeavailable via the content manager of FIG. 1 in accordance with oneembodiment;

FIGS. 3-12 are screen shots illustrating how the functions of FIG. 2 canbe presented to a user;

FIG. 13 is a diagram illustrating an example mobile community platformin accordance with one embodiment;

FIG. 14 is a diagram illustrating the mobile community platform of FIG.13 in more detail;

FIG. 15 is a flow chart illustrating an example process by which acontent provider can create and register a mobile application pod withthe mobile community platform of FIG. 13 in accordance with oneembodiment;

FIG. 16 is a diagram illustrating an example mobile pod in accordancewith one embodiment;

FIG. 17 is a diagram illustrating an example user profile page aspresented by the mobile community platform of FIG. 13 in accordance withone embodiment; and

FIG. 18 is a diagram illustrating an example mobile community platformin accordance with another embodiment.

DETAILED DESCRIPTION

The aforementioned '921 application provides a thorough description of acommunity platform for access by users of many different wirelessnetwork carriers that allows the users to efficiently and effectivelyform a virtual community for communication, sharing, and access to alarge number of third-party application pods that provide services andproducts to users of the community platform, where the third-partyapplication pods are developed and operated by third-parties and thenintegrated with the community platform.

Referring to FIG. 2 of the '921 application, included herein as FIG. 13,a mobile community 202 is accessible to users 212-216 through theinternet 210 or to users 224-228 through their respective cellularcarrier systems 204-208. In this manner, users of mobile community 202can access applications and services provided through mobile community202 either through their mobile phones or through their computerbrowsers.

Referring to FIG. 3 of the '921 application, included herein as FIG. 14,an architecture is depicted which allows application developers toregister their application pods with the community platform of themobile community 202 for access, purchase and use by users of mobilecommunity 202. Briefly, mobile community 202 shown in FIG. 14 includesglobal mobile platform 306, user area 304 where the content, communityand commerce functions are handled for the users, and a multimediamessaging system 302. Users 212, 214, 216 can visit the user area 304 toparticipate in an on-line community that includes various content andcommerce opportunities. This is typically accomplished via a user's webbrowser that may be hosted on a laptop or desktop computer, or, in thealternative, even on the user's mobile device such as a PDA or mobilephone. Thus, user area 304 includes a web server that communicates withusers 212, 214, 216 and includes a data store of user information andother content. With these resources, mobile community 202 presents to auser 212 a profile page (“home page”) that reflects content andinformation associated with, and desired by, that particular user. Thiscontent and information is not maintained on the local computer beingused by the user 212 but, rather, is maintained and managed by thecomputer systems within the user area 304.

Multimedia messaging system 302 includes applications for connectingwith and communicating with the multiple different wireless networkcarriers 204, 206, 208 that have been partnered with the platform ofmobile community 202. MMS 302 is configured to generate message requestsin the appropriate format for each of the wireless network carriers 204,206, 208 including tariff information that determines the amount forwhich the recipient of the message will be charged. Upon receipt of themessage request, the wireless network carriers 204, 206, 208 will usethe information in the request to generate an appropriate message to theintended recipient/subscriber of the cellular carrier and then bill therecipient/subscriber's cellular service account for the specifiedamount.

MMS 302 communicates with the user area 304, such that users of themobile community 202 can advantageously use the connectivity of MMS 302with the carriers in order to send messages to subscribers of any of thewireless network carriers 204, 206, 208. The messages may be SMSmessages, MMS messages, or other message formats that are subsequentlydeveloped. Some of these messages may have zero tariff and, therefore donot generate a bill (other than the underlying charges implemented bythe cellular carrier) and others may have non-zero tariffs resulting ina billing event for the recipient. Mobile users can also communicate viaMMS 302 with user area 304 to access the content, community and commerceoffered though mobile community 202.

Global mobile platform 306 provides a link between third-party softwaredevelopers/providers 308, 310 and mobile community 202. In particular,by using an interface 312, a third-party software provider 308, 310 mayoffer services and products to users 212, 214, 216. Advantageously forthe software provider 308, 310, the global mobile platform 306 alsoprovides automatic and instant connectivity to the MMS 302 and thewireless network carriers 204, 206, 208, and their users. Accordingly,the third-party software provider 308, 310 can interact with all usersof the mobile community 202 whereby billable transactions with users212, 214, 216 are automatically billed via the billing systems of thewireless network carriers 204, 206, 208. Furthermore, and importantly,this capability is available to the third-party software provider 308,310 without requiring the software provider 308, 310 to negotiate orcontract with any cellular carrier for billing arrangements, or to worryabout how to communicate with a cellular carrier's systems andresources. The software provider seamlessly takes advantage of theunified set of connectivity and billing arrangements that exist betweenthe mobile community 202 and the wireless network carriers 204, 206,208. Thus, in addition to the contractual arrangements and affiliationsthe mobile community 202 has in place with different wireless networkcarriers 204, 206, 208, the underlying technical and communicationsinfrastructure is also in place to communicate with and interoperatewith each of the different wireless network carriers 204, 206, 208. As aresult, application pod vendors and other members of the mobilecommunity may interface with and operate with any of a variety ofdifferent carriers without difficulty. While some applications that areavailable to users 212, 214, 216 may be hosted in the user area 304, theglobal mobile platform 306, or elsewhere in the community 202, it isoften the case that the third-party developer/provider 308, 310 willhost their own application at their own remote location.

It should be noted that mobile platform 202 can also provide billingservices through a variety of payment systems. In other words, thebilling events generated in the system are not necessarily limited tomobile billing events. Rather, mobile platform can have agreements witha variety of differnet payment and transaction systems and allowproviders 308, 310 to benefit from these arrangements without the needto have arrangements of their own. This can enable providers 308, 310 toreach an even wider pool of potential customers. Co-pending U.S. patentapplication Ser. No. 11/605,203, filed Nov. 27, 2006, and entitled“System and Method for Verification of Identity for Transactions,” whichis incorporated herein by reference as if set forth in full, describesvarious methods for registering users for various payment services andverifying the users when a billing event is generated.

FIG. 4 of the '921 application, included herein as FIG. 15, depicts aflowchart showing the basic steps through which a third-partyapplication pod developer takes advantage of the community and billingresources offered by the mobile community. First, the applicationdeveloper identifies a service need (such as a stock price informationservice, for example) in step 402, and then the application developerdesigns and develops an application pod for the desired service (step404). In step 406, the developer registers the pod with the communitythrough global mobile platform 306 to make the pod available to users ofmobile community 202 for purchase and use. Once registered, the systemdatabases and directories of mobile community 202 are updated toaccommodate the new pod for access, billing, and other purposes (step408). An example of an application pod developed by a developer andregistered with mobile community 202 is shown in FIG. 9 of the '921application, included herein as FIG. 16, and a depiction of a user'shome page is shown in FIG. 10 of the '921 application, included hereinas FIG. 17, in which it can be seen that the user's home page containsseveral application pods to which the user has subscribed.

As mentioned above, the present invention of this application isdirected to providing an efficient and inexpensive way for a wirelessnetwork carrier to track and monitor third-party content applications(pods) that are accessed by, and billed to, users of the wirelessnetwork carrier, and to control access to, and billing practices of,such third-party content applications (pods) based on selectablecriteria for the performance and user-based feedback related to eachcontent application (pod).

FIG. 1 of the present application is a block diagram that depicts theintegration of a content monitor functionality into the community-basedarchitecture discussed above with respect to FIGS. 13 and 14 in whichthird-party application developers register their application pods withthe community platform of the mobile community for access, purchase anduse by users of the mobile community, and for automatic billing to thewireless network carrier account of a user when that user purchases(opts into) and uses an application pod. In this regard, the componentsof FIG. 1 are similar to those shown in FIGS. 13 and 14, with theexception of the additional components that provide the content monitorfunctionality.

As seen in FIG. 1, the community platform based architecture is shown inwhich third-party application pods 308-310 are integrated into thecommunity 202 through global community platform 306. The applicationpods can then be accessed and purchased for use by users 370 (includingusers 224 to 228) of wireless network carriers 204 to 208, respectively.Content monitor 350 is shown in FIG. 1 to be integrated into thearchitecture such that it is in communication with MMS 302, user area304 and global mobile platform 306. In this way, content monitor 350 canprovide information regarding the use, billing structure and performanceof each application pod to a wireless network carrier, and can alsocontrol a users access to, and purchase of, an application pod. Contentmonitor 350 can be a program or set of executable instructions that canbe executed on a computer or server, either along with the othercomponents shown in community 202 of FIG. 1, or separately, but incommunication with the other components of community 202.

In one embodiment, the functionality of content monitor 350 is accessedby mobile service providers 204 to 208 through content monitor webportal 360. In this regard, content monitor web portal 360 is a securewebsite developed and maintained by community 202 for secure access bymobile service providers 204 to 208. Content monitor web portal 360 canbe accessed through, e.g., a networked computer, such as a typicalpersonal computer or workstation with network access to the internet.

FIG. 2 is a block diagram that explains the functionality of contentmonitor 350 of FIG. 1, e.g., when accessed through content monitor webportal 360. As seen in FIG. 2, one of mobile service providers 204 to208 accesses content monitor web portal 360 by providing a secureidentification, such as an identifier code and a password. Once loggedinto content monitor web portal 360, an application pod list display 361is provided which lists all application pods that are offered to usersthrough the specific mobile service provider that is logged into contentmonitor web portal 360. An example of application pod list display 361is shown in the screen shot of FIG. 3, and shows a listing of allapplication pods offered through the mobile service provider, along withvarious data fields in the row corresponding to each application pod.Each of these various data fields is discussed in more detail below.

From application pod list display 361, a user can click on one of thelisted application pods to bring up a selected pod monitor view 380. Anexample of selected pod monitor view 380 also shown in the middle of thescreen shot of FIG. 3, for application pod “Hottie or NOT.” As can beseen, a selected pod monitor view 380 can include a mobile marketingexposure control bar that can be configured to allow the mobile serviceprovider to control how often the specific application pod is advertisedto the users of the mobile service provider when users are accessinguser area 304 of community 202. Selected pod monitor view 380 alsoincludes a “Read Comments” button, a “View Pricing” button, and a“Suspend Mobile Pod” button, each of which is described further below.

Returning to FIG. 2, each of the various data field functions 381 to 388are shown. In certain embodiments, a display of the data field functionpops-up when the mouse is pointed over that field function in the row ofthe corresponding application pod, e.g., in the list display of FIG. 3.“Total Users” function 381 can allow the mobile service provider to seethe total number of users that have currently purchased (opted into) theselected application pod. An example of a display of the “Total Users”is shown in the screen shot of FIG. 4. “Opt-ins” function 382 can allowthe mobile service provider to see the number of users that have optedinto (purchased) the selected application pod during the current month.An example of a display of the “Opt-ins” is shown in the screen shot ofFIG. 5. “Opt-outs” function 383 can allow the mobile service provider tosee the number of users that have opted out of (canceled) the selectedapplication pod during the current month. An example of a display of the“Opt-outs” is shown in the screen shot of FIG. 6.

In certain embodiments, the user does not necessarily opt-in/opt-out asthose terms may normally be defined. Rather, the terms opt-in/opt-outcan be used more generically to refer to the simpleactivation/de-activation of a pod, regardless of the actual mechanismfor activating/de-activating.

“Revenue Last Month” function 384 can allow the mobile service providerto see the total amount of revenue billed by the selected applicationpod through the mobile service provider for the last (previous) month.An example of a display of the “Revenue Last Month” is shown in thescreen shot of FIG. 7. “Revenue This Month” function 385 can allow themobile service provider to see the total amount of revenue billed by theselected application pod through the mobile service provider for this(current) month. An example of a display of the “Revenue This Month” isshown in the screen shot of FIG. 8. “User Rating” function 386 can allowthe mobile service provider to see the composite user rating based onrating input from the users in the community that use the selectedapplication pod, and is shown in the form of one-to-five stars, asindicated for each application pod in the screen shot of FIG. 3.

“Complaints” function 387 can allow the mobile service provider to seethe total number of complaints related to the selected application podas provided by users in the community that use the selected applicationpod, as indicated for each application pod in the screen shot of FIG. 3.For example, FIG. 15 of the '921 application is a flow chartillustrating an example method for instituting a complaint departmentwithin mobile community 202. In exemplary embodiments, the mobileservice provider can also read the subject complaints for a selectedapplication pod. Lastly, “Status” function 388 can allow the mobileservice provider to track and monitor the performance of the selectedapplication pod, and to control access and purchase of the selectedapplication pod based on criteria selected by the mobile serviceprovider for the selected application pod. The current status of theselected application pod is shown in the row corresponding to theapplication pod, as seen in FIG. 3, and the status is depicted by acolored button, such as green for “good,” yellow for “warning,” and redfor “suspension”. In this way, the mobile service provider can easilysee if there is a problem with a specific application pod or if theapplication pod needs to be suspended so that users of mobile serviceprovider can no longer access or purchase the application pod.

The colored status indicators of “Status” function 388 are based on thenumber of complaints from users of the selected application pod, incomparison, e.g., to a selected sensitivity (threshold) criteria set bythe mobile service provider. In this regard, an example of a display ofthe “threshold” setting of the “Status” function is shown in the“threshold” pop-up box in the right side of the screen shot of FIG. 11.As seen in FIG. 11, the buttons are provided for “Automatic Suspension”or “Manual Suspension”, which the mobile service provider can selectdepending on whether it is desired for content monitor 350 toautomatically suspend an application pod that has a number of complaintsexceeding a set threshold, or whether content monitor 350 is simply towarn the mobile service provider that the threshold has been exceed byturning the status indicator to red, and then the mobile serviceprovider must manually suspend the application pod, as described below.

Also provided in the “threshold” pop-up box shown in FIG. 11 is a“threshold” setting bar which allows the mobile service provider to setthe level of user complaints (based on percentage of users thatpurchased the application pod) required as a threshold for the statusindicator to turn from green (good standing) to yellow (warning), andfrom yellow (warning) to red (suspend). In this manner, the mobileservice provider can decide how strictly they want to control thequality of application pods that are offered to users through the mobileservice provider.

Also provided in the “threshold” pop-up box is an average “threshold”bar which displays the average threshold levels set for all mobileservice providers in a given region, such as the United States. Thisallows a specific mobile service provider to see how all other mobileservice providers are controlling access to, and purchase of, a specificapplication pod. Based on the aforementioned thresholds and buttonsettings set by the mobile service provider in the “threshold” pop-upbox, the status indicator is shown in application pod list display 361is set to the appropriate color according to the number of complaintsreceived in community 202 from users of the selected application pod. Ifthe threshold for suspension is crossed based on the number ofcomplaints, the status indicator is set to “red”, and the applicationpod is automatically suspended from access and use by content monitor350 if “automatic suspension” button has been set by the mobile serviceprovider. Otherwise, the mobile service provider must notice the redstatus indicator and then manually suspend the application pod. Eitherway, when an application pod is suspended, content monitor 350coordinates with global mobile platform 306 and user area 304 to preventthe suspended application pod from being accessed and purchased by usersof the mobile service provider (carrier).

It should be noted that the threshold should be based on reasonablepercentage as oppose to say an overall number of complaints. Clearly apod that generates millions of messages will often also generate morecomplaints than say a pod that generates a few thousand messages;however, the percentage may be much lower. For example, a pod thatgenerates one million messages may generate 10,000 complaints. But thismeans that a complaint is generated only 1% of the time. If the pod onlygenerates one hundred thousand messages, then the same 10,000 complaintswould represent a 10% complaint rate. Clearly the second example is moreof a problem than the first. Therefore, thresholds based on a percentageor rate of complaints can be more useful than thresholds based on volumeof complaints. In certain embodiments, however, the raw number ofcomplaints can be used either alone or in combination with a rateanalysis.

In other embodiments, the number of opt-outs, or de-activations can alsobe used to determine whether to suspend a certain pod with respect to acertain carrier and/or, as explained below, a certain aggregator. Forexample, in certain embodiments, a opt-out/de-activation threshold canbe set that when crossed causes content monitor 350 to automaticallysuspend the pod for the specific carrier. Further, the status indicationcan also be generated based on the number of opt-outs/de-activations. Ifautomatic suspension is not enabled, then the status indicator can alertthe carrier to the situation so that the carrier can make adetermination regarding manual suspension based on the rate ofopt-outs/de-activations. In other embodiments, the status indicatorand/or automatic suspension can be based on a combination of complaintsand opt-outs.de-activations.

Returning to FIGS. 2 and 3, the “Read Comments” button function 391 ofselected pod monitor view 380 can allow the mobile service provider(carrier) to view all comments entered by users of the selectedapplication pod, as shown in FIG. 9. Similarly, the “View Pricing”function 392 of selected pod monitor view 380 can allow the mobileservice provider (carrier) to view the pricing model of the selectedapplication pod, along with information of the third party that operatedthe selected application pod. This allows the mobile service provider toensure that the pricing model and information is in the correct formatas presented to users, and to ensure that it is fair and clear, as shownin FIG. 10. Lastly, the “Suspend Mobile Pod” function 393 of selectedpod monitor view 380 can allow the mobile service provider (carrier) tosuspend an application pod from use for any reason, such as when thestatus indicator is red in the status display of the selectedapplication pod in the application pod list display 361. FIG. 12 showsan example of a “Suspend Mobile Pod” pop-up display that can bedisplayed upon operation of the “Suspend Mobile Pod” button of selectedpod monitor view 380. As seen in FIG. 12, the mobile service providercan elect to suspend the application pod from service through the mobileservice provider for a specific amount of time, such as one day, oneweek, or one month, or indefinitely.

Thus, as described above, a mobile carrier can control the contentprovided to its customers through mobile platform 202 in a manner thatcuts down on complaints and increases customer satisfaction; however, aswill be understood there is often a middle man involved when it comes toproviding content to mobile users. These middlemen are often referred toas “Aggregators.” For example, it is well understood that short codesassociated with SMS messaging are actually managed by an Aggregator.When a mobile user sends a message using a short code, the message, andany reply, are routed through the Aggregator's system. The Aggregator isthen in charge of collecting all fees associated with the message andforwarding the respective shares, e.g., to the associated carrier andthe service/content provider associated with the short code. TheAggregator also makes a small transaction fee for handling each message.Other intermediaries, such as transaction processors, e.g., Paypal or abank, can also perform some or all of the functions of an aggregator asdescribed herein.

This type of arrangement is illustrated in FIG. 18. As can be seen,mobile platform 202 is interfaced with a plurality of mobile carriers,204-208 through aggregators 1802, 1804, 1806. It will be understood thatmore or less carriers can be interfaced with mobile platform 202 viamore or less aggregators and that number of carriers and aggregatorsillustrated in FIG. 18 is by way of example only and not intended tolimit the embodiments described herein to specific numbers of carriersor aggregators. Further, it will be understood that some of aggregators1802, 1804, 1806 will have contracts to provide messaging services withonly certain of carriers 204, 206, 208 and may not have contracts toprovide messaging services for all carriers 204, 206, 208. Similarly,mobile platform 202 may have contracts with each of aggregators 1802,1804, 1806 to handle messages for only certain of carriers 204, 206,208. Thus, aggregators 1802, 1804, 1806 can provide message routing andfee collection and allocation services for mobile users 224, 226, 228when accessing the pods of mobile platform 202.

Aggregators 1802, 1804, 1806 can also be very sensitive to complaintsassociated with messages being provide via the application pods, becausethey do not want to risk being dropped as an aggregator by carriers 204,206, 208. Accordingly, in certain embodiments, aggregators 1802, 1804,1806 can use the services provided by content monitor 350 and accessedvia content monitor portal 360.

The aggregator can then access the functions of FIG. 2 and illustratedin the screen shots of FIGS. 3-12; however, the information displayedwill be with respect to the aggregator and not the carrier. Further, thethresholds of FIG. 11 can be provided per carrier per aggregator. Inother words, an aggregator can select a higher threshold for one carrierversus another. When a carrier specific threshold for a certainaggregator is exceeded, then mobile platform 202 will not send anymessages intended for a mobile user associated with the carrieroriginating from the offending pod through the particular aggregator.But mobile platform 202 may continue to send messages from the offendingpod to user's associated with the specific carrier through anotheraggregator if the associated threshold for that aggregator has not beenexceeded.

In other words, aggregators 1802, 1804, 1806 can define a threshold foreach carrier 204, 206, 208 they are servicing. If aggregators 1802 and1804 are both servicing carrier 204, then messages for users of carrier204 can be routed through both aggregators 1802 and 1804. For example, atype of load balancing may be employed using both aggregators. In otherembodiments, pricing may dictate which aggregator is used. If messagesassociated with a pod exceed the threshold set by aggregator 1802, themobile platform 202 can automatically stop sending messages associatedwith the pod to users of carrier 204 through aggregator 1802; however,mobile platform 202 may still send messages associated with the pod touser's of carrier 204 through aggregator 1804, provided the thresholdset by aggregator 1804 is not also exceeded.

It should be noted that the systems and methods described above and inrelated applications such as the '921 application should help ensuregreater customer satisfaction, because for example the systems andmethods ensure that the user is not billed unless they opt in and theuser is billed the amount agreed upon. But in the event a particular podstill generates complaints, the aggregator, or carrier can simply shutdown access to that pod. Thus, the carriers do not need to expend theresources required to deal with such situations, and the aggregators canpreserve their relationships with the various carriers by eliminating aproblem before it reaches a level where the carriers will start payingattention.

Another problem for aggregators is that content providers are constantlyjumping from one aggregator to another, e.g., in an attempt to getbetter pricing. As a result, the aggregator's margins are constantlybeing squeezed. Accordingly, in certain embodiments, content providerscan sign up and register pods to be made available by mobile platform202 via an aggregator 1802, 1804, 1806. In other words, aggregators1802, 1804, 1806 can offer, e.g., via a link on their web pages, theability for content providers to provide content via an application podand mobile platform 202.

For example, an aggregator can develop a marketing page that includes alink to mobile platform 202. When a content provider access themarketing page and clicks on the link, they will be interfaced withplatform 202 where they can register their pod, e.g., in accordance withthe process described in relation to FIG. 14. The content providers podwill then be made available as illustrated in FIGS. 16 and 17. Incertain embodiments, all messages associated with that pod can then berouted through the aggregator through which the content provideraccessed platform 202. In this manner, the aggregator can drive moremessages, and therefore more revenue, through the aggregator's system.

In other embodiments, the aggregator can be paid an additional fee,e.g., 5% of the revenue assigned to mobile platform 202 and/or thecontent provider. In other embodiments, messages associated with the podare not necessarily routed through the associated content provider, butthe revenue share fee, e.g., 5%, can apply regardless of what aggregatorthe message is sent through. Thus for example, if messages are sentwithin a geographic area serviced by the aggregator, then the messagescan be routed through the aggregator. But the messages can be routedthrough other aggregators in other geographic regions, thereby drivingadditional revenue for all parties involved.

In other words, in the embodiment of FIG. 18, each aggregator 1802,1804, 1806 can be servicing a particular geographic region. All messagesrouted to at least certain carriers in the associated region can beroute through the associated aggregator 1802, 1804, 1806; however, if amessage being routed through one aggregator is related to a pod that wasregistered through one of the other aggregator's marketing pages, thenthe other aggregator can still get a share of the processing feecollected in association with the message.

Moreover, in certain embodiments, the pod can be permanently associatedwith the originating aggregator for the purpose of fee splitting/revenuesharing as described above. For example, even if the content provider ofthe pod jumps to another aggregator, which as explained above is verycommon, then the originating aggregator can still receive a share of thefees generated by that pod.

It should be noted that the systems and methods describe above aregenerally related to wireless network carriers and associatedaggregators; however, as is mentioned above, mobile platform 202 can beconfigured to provide message and billing capabilities through a varietyof systems and intermediaries, including non-mobile systems andintermediaries. Accordingly, the operators of these systems and/orintermediaries can have similar concerns about network-enabledapplications that generate a lot of complaints and/or de-activationrequests. Thus, the ability to suspend a network-based application asdescribed above can also be made available to these non-mobile entities.Further, the non-mobile intermediaries can have the ability to sign upcontent providers and share in revenue generated by messages associatedwith the content provider's application in a manner similar to thatdescribed for mobile intermediaries.

While certain embodiments of the inventions have been described above,it will be understood that the embodiments described are by way ofexample only. Accordingly, the inventions should not be limited based onthe described embodiments. Rather, the scope of the inventions describedherein should only be limited in light of the claims that follow whentaken in conjunction with the above description and accompanyingdrawings.

1. A method for providing a plurality of network-enabled application toa plurality of users via a plurality of communication channels with arespective plurality of wireless network carriers, the methodcomprising: a request receipt step of receiving, at the platform, arequest from one of the plurality of wireless network carriers for alist of network-enabled applications being provided to users associatedwith the requesting wireless network carrier; a listing step ofproviding, at the platform, the list to the requesting wireless networkcarrier, the list including the name, user information, revenueinformation, and status of each network-enabled application beingprovided via the requesting wireless network carrier; a complaintreceipt step of receiving, at the platform, complaints associated withthe plurality of network-enabled applications from the plurality ofusers; and a status update step of updating, at the platform, statusinformation for each of the plurality of network-based application basedon the complaints received in the complaint receipt step.
 2. The methodof claim 1, further comprising a threshold evaluation step of comparing,at the platform, the number of complaints received for each of theplurality of network-enabled applications with a pre-determinedcomplaint threshold, and wherein the status is updated based on thecomparison.
 3. The method of claim 2, further comprising a thresholdreceipt step of receiving, at the platform, complaint thresholdinformation from the plurality of wireless network carriers.
 4. Themethod of claim 2, further comprising a disabling step of disabling, atthe platform, a network-enabled application for one of the plurality ofwireless network carriers when the complaint threshold for the wirelessnetwork carrier is exceeded for the network-enabled application.
 5. Themethod of claim 1, wherein user information includes the total number ofusers for each of the plurality of network-enabled applications beingprovided via the requesting wireless network carrier.
 6. The method ofclaim 1, wherein user information includes the number of activations inthe current month for each of the plurality of network-enabledapplications being provided via the requesting wireless network carrier.7. The method of claim 1, wherein user information includes the numberof de-activations for each of the plurality of network-enabledapplications being provided via the requesting wireless network carrier.8. The method of claim 1, wherein user information includes user ratingsfor each of the plurality of network-enabled applications being providedvia the requesting wireless network carrier.
 9. The method of claim 1,wherein revenue information includes the total revenue generated for therequesting wireless network carrier by each of the plurality ofnetwork-enabled applications being provided via the requesting wirelessnetwork carrier.
 10. The method of claim 1, wherein revenue informationincludes the revenue generated in the current month for the requestingwireless network carrier by each of the plurality of network-enabledapplications being provided via the requesting wireless network carrier.11. The method of claim 1, wherein revenue information includes thetotal revenue generated in the previous month for the requestingwireless network carrier by each of the plurality of network-enabledapplications being provided via the requesting wireless network carrier.12. The method of claim 1, further comprising for each of the pluralityof network-enabled applications: a registration data receipt step ofreceiving, at the platform, a set of registration data corresponding tothe network-enabled application from a third-party provider, the set ofregistration data including a link to an application location foraccessing the network-enabled application; a pricing structure datareceipt step of receiving, at the platform, a set of pricing structuredata corresponding to the network-enabled application from thethird-party provider; a database update step of updating a systemdatabase in the platform to include the set of registration datacorresponding to the network-enabled application and to include thepricing structure data corresponding to the network-enabled application;and an enablement step of enabling the network-enabled application to beaccessible to the plurality of users via a networked interface operatedby the platform.
 13. The method of claim 1, wherein the plurality ofwireless network carriers included a plurality of wireless networkcarriers and a plurality of intermediaries.
 14. A method for providing aplurality of network-enabled application to a plurality of users via aplurality of communication channels with a respective plurality ofwireless network carriers, the method comprising: a request receipt stepof receiving, at the platform, a request from one of the plurality ofwireless network carriers for a list of network-enabled applicationsbeing provided to users associated with the requesting wireless networkcarrier; a listing step of providing, at the platform, the list to therequesting wireless network carrier, the list including the name, userinformation, revenue information, and status of each network-enabledapplication being provided via the requesting wireless network carrier;a de-activation request receipt step of receiving, at the platform, arequests to de-activate at least some of the plurality ofnetwork-enabled applications from the plurality of users; and a statusupdate step of updating, at the platform, status information for each ofthe plurality of network-based application based on the de-activationrequests received in the de-activation request receipt step.
 15. Themethod of claim 14, further comprising a threshold evaluation step ofcomparing, at the platform, the number of de-activation requestsreceived for each of the plurality of network-enabled applications witha pre-determined de-activation request threshold, and wherein the statusis updated based on the comparison.
 16. The method of claim 15, furthercomprising a threshold receipt step of receiving, at the platform,de-activation request threshold information from the plurality ofwireless network carriers.
 17. The method of claim 15, furthercomprising a disabling step of disabling, at the platform, anetwork-enabled application for one of the plurality of wireless networkcarriers when the de-activation request threshold for the wirelessnetwork carrier is exceeded for the network-enabled application.
 18. Themethod of claim 14, wherein user information includes the total numberof users for each of the plurality of network-enabled applications beingprovided via the requesting wireless network carrier.
 19. The method ofclaim 14, wherein user information includes the number of activations inthe current month for each of the plurality of network-enabledapplications being provided via the requesting wireless network carrier.20. The method of claim 14, wherein user information includes a numberof complaints received for each of the plurality of network-enabledapplications being provided via the requesting wireless network carrier.21. The method of claim 14, wherein user information includes userratings for each of the plurality of network-enabled applications beingprovided via the requesting wireless network carrier.
 22. The method ofclaim 14, wherein revenue information includes the total revenuegenerated for the requesting wireless network carrier by each of theplurality of network-enabled applications being provided via therequesting wireless network carrier.
 23. The method of claim 14, whereinrevenue information includes the revenue generated in the current monthfor the requesting wireless network carrier by each of the plurality ofnetwork-enabled applications being provided via the requesting wirelessnetwork carrier.
 24. The method of claim 14, wherein revenue informationincludes the total revenue generated in the previous month for therequesting wireless network carrier by each of the plurality ofnetwork-enabled applications being provided via the requesting wirelessnetwork carrier.
 25. The method of claim 14, further comprising for eachof the plurality of network-enabled applications: a registration datareceipt step of receiving, at the platform, a set of registration datacorresponding to the network-enabled application from a third-partyprovider, the set of registration data including a link to anapplication location for accessing the network-enabled application; apricing structure data receipt step of receiving, at the platform, a setof pricing structure data corresponding to the network-enabledapplication from the third-party provider; a database update step ofupdating a system database in the platform to include the set ofregistration data corresponding to the network-enabled application andto include the pricing structure data corresponding to thenetwork-enabled application; and an enablement step of enabling thenetwork-enabled application to be accessible to the plurality of usersvia a networked interface operated by the platform.
 26. The method ofclaim 14, wherein the plurality of wireless network carriers included aplurality of wireless network carriers and a plurality ofintermediaries.
 27. A method for integrating a network-enabledapplication with a platform having a plurality of users and a pluralityof communication channels with a respective plurality of wirelessnetwork carriers, the plurality of communication channels including anintermediary system operated by an intermediary, the method comprising:a request receipt step of receiving, at the platform, a request from athird-party provider to integrate a network-enabled application with theplatform; a registration data receipt step of receiving, at theplatform, a set of registration data corresponding to thenetwork-enabled application from the third-party provider, the set ofregistration data including a link to an application location foraccessing the network-enabled application, wherein the set ofregistration data is received from the third-party provider through aregistration webpage operated by the intermediary; a pricing structuredata receipt step of receiving, at the platform, a set of pricingstructure data corresponding to the network-enabled application from thethird-party provider; a database update step of updating a systemdatabase in the platform to include the set of registration datacorresponding to the network-enabled application and to include thepricing structure data corresponding to the network-enabled application;and an enablement step of enabling the network-enabled application to beaccessible to the plurality of users via a networked interface operatedby the platform.
 28. The method of claim 27, wherein the set ofregistration data includes an application identifier corresponding tothe network-enabled application, and a provider identifier correspondingto the third-party.
 29. The method of claim 27, wherein, in the pricingstructure data receipt step, the pricing structure data is received fromthe third-party provider through a pricing structure webpage operated bythe intermediary.
 30. The method of claim 27, wherein the platformincludes an application interface platform and wherein, in theenablement step, the network-enabled application is integrated with theplatform via the application interface platform.
 31. The method of claim27, wherein the platform includes a message management system forsending messages to the plurality of users via the intermediary systemand the plurality of communication channels with the respectiveplurality of wireless network carriers and wherein, in the enablementstep, a message communication channel is established between thenetwork-enabled application and the message management system.
 32. Themethod of claim 27, wherein the registration data received in theregistration data receipt step includes an intermediary identificationassociated with the intermediary.
 33. A method for providing a pluralityof network-enabled application to a plurality of users via a pluralityof communication channels with a respective plurality of messagesystems, the method comprising: a request receipt step of receiving, atthe platform, a request from one of the plurality of message systems fora list of network-enabled applications being provided to usersassociated with the requesting message system; a listing step ofproviding, at the platform, the list to the requesting message system,the list including the name, user information, revenue information, andstatus of each network-enabled application being provided via therequesting message system; a complaint receipt step of receiving, at theplatform, complaints associated with the plurality of network-enabledapplications from the plurality of users; and a status update step ofupdating, at the platform, status information for each of the pluralityof network-based application based on the complaints received in thecomplaint receipt step.
 34. The method of claim 33, further comprising athreshold evaluation step of comparing, at the platform, the number ofcomplaints received for each of the plurality of network-enabledapplications with a pre-determined complaint threshold, and wherein thestatus is updated based on the comparison.
 35. The method of claim 34,further comprising a threshold receipt step of receiving, at theplatform, complaint threshold information from the plurality of messagesystems.
 36. The method of claim 34, further comprising a disabling stepof disabling, at the platform, a network-enabled application for one ofthe plurality of message systems when the complaint threshold for themessage system is exceeded for the network-enabled application.
 37. Themethod of claim 33, wherein user information includes the total numberof users for each of the plurality of network-enabled applications beingprovided via the requesting message system.
 38. The method of claim 33,wherein user information includes the number of activations in thecurrent month for each of the plurality of network-enabled applicationsbeing provided via the requesting message system.
 39. The method ofclaim 33, wherein user information includes the number of de-activationsfor each of the plurality of network-enabled applications being providedvia the requesting message system.
 40. The method of claim 33, whereinuser information includes user ratings for each of the plurality ofnetwork-enabled applications being provided via the requesting messagesystem.
 41. The method of claim 33, wherein revenue information includesthe total revenue generated for the requesting message system by each ofthe plurality of network-enabled applications being provided via therequesting message system.
 42. The method of claim 33, wherein revenueinformation includes the revenue generated in the current month for therequesting message system by each of the plurality of network-enabledapplications being provided via the requesting message system.
 43. Themethod of claim 33, wherein revenue information includes the totalrevenue generated in the previous month for the requesting messagesystem by each of the plurality of network-enabled applications beingprovided via the requesting message system.
 44. The method of claim 33,further comprising for each of the plurality of network-enabledapplications: a registration data receipt step of receiving, at theplatform, a set of registration data corresponding to thenetwork-enabled application from a third-party provider, the set ofregistration data including a link to an application location foraccessing the network-enabled application; a pricing structure datareceipt step of receiving, at the platform, a set of pricing structuredata corresponding to the network-enabled application from thethird-party provider; a database update step of updating a systemdatabase in the platform to include the set of registration datacorresponding to the network-enabled application and to include thepricing structure data corresponding to the network-enabled application;and an enablement step of enabling the network-enabled application to beaccessible to the plurality of users via a networked interface operatedby the platform.
 45. The method of claim 33, wherein the plurality ofmessage systems included a plurality of message systems and a pluralityof intermediaries.